Como economizamos 36h de trabalho por semana com a automação de builds?
O App Consultoria, que atende nosso público de consultoras Natura, cresceu muito com o passar dos anos, tanto em funcionalidades, quanto serviços e produtos oferecidos, e se transformou em um SuperApp, como falamos em nosso artigo anterior. Com isso, o número de versões que geramos do app e a quantidade dessas versões aumentaram de maneira exponencial.
Ainda quando atuávamos de forma muito orientada a projetos e não a produtos, antes de passarmos por uma transformação digital, o trabalho de gerar versões do aplicativo e colocar em produção às vezes ficava mascarado dentro de outras atividades que eram necessárias para entrega de funcionalidades, e passava um tanto quanto despercebido. E, com isso, não era raro que houvesse atraso no lançamento de algumas versões do aplicativo, e também comentários como: “Nossa, mas esse app é demorado, é complicado demais!”. Essa, infelizmente, era a percepção que nossos usuários de negócio tinham naquela época, quando faziam um projeto com o time de tecnologia.
Esses atrasos ocorriam pois não tínhamos conhecimento de quantas versões seriam necessárias, quanto tempo o nosso app demorava para gerar novas versões, ou por que o nosso SuperApp demorava tanto para gerar versões, e não tínhamos tempo hábil para fazer esta análise.
Algumas perguntas sempre passavam pelos corredores: “O Android demora o mesmo tempo que o iOS?”, “Mas, se tivéssemos um computador melhor, seria mais rápido?”, “Como podemos gerar menos versões do app?”, “não é possível fazer como no web, onde entregamos atualizações sem a necessidade de fazer um pacote e esperar os usuários instalarem?”
E, ao longo do tempo, amadurecemos a forma de responder a todos esses questionamentos. Precisamos lembrar que a tecnologia nasceu primeiro orientada a web. As companhias de forma geral começaram suas plataformas através da web. Então é natural que se tenha que amadurecer também a forma de se enxergar a web e o mobile dentro de uma companhia. Todos os processos, aprovações, ferramentas e suporte estavam orientados a web. Até a chegada do nosso SuperApp, que não se encaixava nesses padrões.
Não existe rollback. Temos que esperar os usuários fazerem download. Se há um bug, no geral, precisamos fazer uma nova versão para corrigir.
E dia após dia fomos deixando mais transparente como os processos precisavam ser, quais ferramentas as plataformas mobile precisam, e como o Mundo Mobile funciona.
E, dessa forma, formamos um time de engenharia. Com isso, as perguntas também foram amadurecendo: o que precisamos fazer para amadurecer o nosso processo de geração de versões? Como podemos automatizar essas etapas? São tantos passos para gerar uma versão de um SuperApp, é tão difícil quando chega um pessoa dev nova no time, como podemos melhorar isso?
Como pesquisamos?
Em geral, a primeira coisa que toda pessoa dev aprende, até antes do Hello World, é como procurar coisas. Até para fazer o Hello World!
Nossa busca (e ansiedade) começou quando fomos procurar o que o mercado estava fazendo, o que existia de tecnologias no momento e o que poderia se adequar ao nosso SuperApp. Foram quase 2 meses, não por burocracias, mas sim porque nosso time queria ter um pouco mais de certeza em relação à ferramenta escolhida, afinal de contas, gostaríamos que essa ferramenta atendesse não somente ao App Consultoria, mas a todos os mais de 10 apps que a Natura possui atualmente nas mais diversas jornadas.
Inicialmente começamos a busca de forma desestruturada. Logo nos dois primeiros dias, já tínhamos perguntas suficientes sem respostas que preenchiam duas páginas de caderno, e não conseguíamos mais lembrar qual ferramenta respondia cada uma dessas perguntas. Resolvemos, então, fazer uma lista das coisas que a ferramenta precisava suportar para que o nosso app pudesse se adequar.
Na época, o aplicativo ainda dava suporte para Android 4 — Android 9 e iOS 9 — iOS 13. A ferramenta também precisava suportar nativo e ReactNative, pois nosso app é híbrido. Nosso tempo para gerar uma versão, com um Superapp com mais de 150 funcionalidades e 12 perfis é razoavelmente grande, girava em torno de 1h e meia naquela época, principalmente no iOS, então, isso precisava ser suportado também. Parte do nosso app ainda é em Objective C no iOS e em Java no Android, e isso não podia ser um impedimento. Essa ferramenta tinha que ser tão genérica que possibilitasse ao final se conectar com a nossa ferramenta de gestão de mudança interna, pois passamos por auditoria. Além de tudo isso, ainda tínhamos que pensar nos testes, que eram uma preocupação e um capítulo à parte, pois nenhuma das ferramentas conseguia nos responder todas as dúvidas que tínhamos e estávamos em um momento de transição de ferramentas de automação de testes e tínhamos mais incertezas que certezas.
Pensamos por algumas vezes em esquecer ferramentas prontas e criar essa automação e deixar dentro de casa, pois temos um bom time de infraestrutura. E pensamos que também precisaríamos manter isso para que desse certo. Nova versão da Apple? Nova versão do xCode? Breaking Change do xCode? E também Android Studio? Isso sem esquecer do React Native, claro. Como administrar isso? Versões, updates e necessidades diferentes para cada app.
Decidimos que naquele momento isso não fazia sentido. Queríamos começar o mais rápido possível. Mas devagar no âmbito corporativo. Um app de cada vez. Com bons processos, bem estabelecidos, com documentação, com processos genéricos que servissem para os demais. Um time quebra as pedras, os demais colhem os frutos. Essa é a nossa missão como System Team para nossas squads. E entendíamos que depois de bem estabelecidos todos os apps, nessa ferramenta, poderíamos olhar pro mercado, ver as ferramentas que existem, e pensar se faziam sentido no nosso contexto como um todo.
Voltamos para a ideia original. Ferramenta. SaaS. De matriz Tem x Não tem, Atende x Não atende, ligações, custo, benefício. Enfim conseguimos, encontramos uma candidata que aparentemente nos atende em tudo o que precisamos.
Escolhemos o Bitrise para esse trabalho, e temos tido sucesso. Vamos entrar no detalhe?
Diferenças entre Android.e iOS?
Como falamos acima, escolhemos o Bitrise como ferramenta de automação das versões do nosso SuperApp.
O Bitrise é uma ferramenta de CI as a service voltado especialmente ao desenvolvimento mobile. Utilizado mundialmente, é uma plataforma simples e rápida com passos pré-definidos e módulos que possibilitam a integração com qualquer aplicativo mobile em pouco tempo.
Usamos o Bitrise seguindo estratégias diferentes entre nossas tecnologias mobile nativas, Android e iOS. Sabemos que cada tecnologia possui suas especificidades e não vemos isso como um problema, mas sim como forma de aprender a lidar com essas diferenças e entender um pouco mais afundo sobre cada plataforma.
Vamos começar a falar sobre Android…
Como uma tecnologia de natureza mais aberta, encontramos no próprio Bitrise formas de resolver nossos problemas sem a necessidade de utilizar outra ferramenta. Para isso, entendemos os steps do Bitrise como um mix de scripts e tarefas do gradle, que todas pessoas desenvolvedoras Android, estão acostumadas a ver:
● gradlew assembleDebug
● gradlew testDebugUnitTest
● gradlew connectedDebugAndroidTest
● etc
Utilizamos então esses fluxos já pré-definidos nos passos do Bitrise, além de outras etapas que nos auxiliaram em tarefas extremamente importantes quando nos referimos ao processo de geração de versão de um aplicativo, como geração das dependências (lembra do React?), assinatura do app, mudança dos números de versão. Enfim, a ferramenta que escolhemos se mostrou pronta para as nossas necessidades do momento, e tem nos ajudado muito.
Sabemos que todas as etapas executadas pelo Bitrise, eram/são executadas localmente, mas ao ter essa execução sendo feita em uma máquina terceira, gerando nossas versões, validando nossos Pull Requests, além de nos poupar muito tempo por semana, nos deu mais segurança e ainda mais certeza que estávamos seguindo pelo caminho certo.
Agora, um pouco sobre como funciona a automação no iOS
Para a automação do processo de geração de versão das nossas apps iOS, utilizamos o Fastlane + Makefile.
O Fastlane é um conjunto de ferramentas de código aberto que facilitam muito o continuos delivery de apps iOS. Elas vão desde compilação e execução de testes ao gerenciamento de certificados e distribuição na App Store. A mágica toda acontece através das lanes, que basicamente são as chamadas dessas ferramentas que o Fastlane disponibiliza. Abaixo estão alguns exemplos dessas lanes e o que elas podem fazer:
· gym: compila o projeto e gera o artefato final da aplicação (Arquivo .ipa)
· match: capaz de criar e instalar os certificados e provisioning profiles necessários ao code signing.
· scan: executa os testes do projeto
· pilot: faz o upload para o Test Flight e gerencia os usuários de teste
· snapshot: gera screenshots de forma automática para ser enviados para a App Store.
Além disso, é possível criar suas próprias lanes, o que traz uma flexibilidade incrível para a construção da sua esteira de integração contínua ou de testes. Você pode usar uma lane privada para fazer algum setup ou inicialização de itens do projeto que você necessita, como a configuração de algum SDK por exemplo.
Já o Makefile, nada mais é do que uma forma fácil de executar todo esse conjunto de ferramentas trazidas pelo Fastlane. Ele basicamente consiste em um arquivo com uma série de instruções shell script que podem ser invocadas através de um único comando. Isso permite que as pessoas desenvolvedoras possam realizar tarefas sequenciais complexas invocando apenas um único comando pelo terminal. Esses comandos por sua vez, chamam as lanes, que fazem todo o trabalho pesado.
No final de tudo, a esteira consiste em uma sequência de passos que executam distintos comandos do Makefile, que vão desde o clone do projeto, instalação de dependências, execução de testes, geração do arquivo .ipa, upload para o Test Flight, entre outras tarefas.
Alguns exemplos de esteiras que temos atualmente:
sanity_check: clona o projeto, instala as dependencias e executa a suite de testes unitarios
build_prd_ipa: gera o arquivo .ipa para ambiente de Produção (Ad-Hoc) e o disponibiliza para download
build_hml_ipa: gera o arquivo .ipa para ambiente de Homologação (Ad-Hoc) e o disponibiliza para download
release_alpha: compila o app e faz o upload diretamente no Test Flight, como versão alpha.
O interessante dessa abordagem é que ela torna nossos processos agnósticos ao serviço de integração contínua que utilizamos (atualmente o Bitrise). Se amanhã decidirmos mudar para algum outro serviço ou até mesmo algo desenvolvido dentro de casa, seria bastante rápido e fácil reescrever nossas esteiras, já que elas basicamente consistem de uma sequência de passos que executam tarefas já definidas no nosso Makefile
E a economia?
Com as ações acima conseguimos economizar cerca de 36h de trabalho por semana com a geração de novas versões desse super app, transformando esse trabalho manual em algo automatizado no Bitrise e deixando nossas pessoas desenvolvedoras com máquinas e tempo disponíveis para fazerem o que mais amam: codar.
Essa economia de tempo nos trouxe muito mais produtividade no dia a dia, pois começamos a conseguir medir o que tomava mais tempo para gerar nossas versões (qual parte? qual módulo? qual biblioteca?), priorizar e trabalhar em cima de otimizações. Além disso, com essa economia de tempo, conseguimos trazer para dentro do mesmo time +1 App, o app que é usado na Latam para que pudesse passar pelas mesmas automações e estivesse equalizado tanto no Brasil, quanto no restante da Latam para nossas consultoras com as mesmas bases de automação e boas práticas de engenharia e CI/CD.
No meio disso tudo, também tivemos um novo desafio: Como centralizar a gestão de certificados no iOS e trabalhar com o fastlane? Vamos falar um pouco sobre isso no próximo artigo.
A autoria desse artigo é de todos membros do System Team da Natura. Bianca Letti — Engineering Manager (Natura), Hamilton César Lucia Junior — Tech Lead (Natura), Angélica Oliveira — Android Developer (Thoughtworks) e Michel Bueno — iOS Developer (Thoughtworks).
